In a Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access Network (UTRAN), some potential bottlenecks exist. Two potential bottlenecks are the air interface and the transport network (transport link) connecting a radio network controller (RNC) with respective radio base stations, Node B. The transport link between the RNC and Node B is a potential bottleneck when its capacity is smaller than the available maximal air interface (Uu) capacity. For example, a typical scenario is that the Node B is connected to the RNC through an E1 link of capacity about 2 Mbps and in this case the available Uu capacity for High Speed Downlink Packet Access (HSDPA) can be significantly larger than 2 Mbps. As a result one single user equipment (UE) with good radio conditions can overload the transport network (TN).
Fair sharing of Uu resources is the task of the Uu scheduler, but the Uu scheduler is not enabled to manage the TN bottleneck (i.e. transport link bottleneck). To deal with the TN bottleneck a flow-control (FC) mechanism has been introduced. In FIG. 1 a protocol stack of a UTRAN system is illustrated. FIG. 1 shows the location of the FC in the protocol stack. Thus, the flow control exist in the shaping of the Media Access Control MAC-d (Media Access Control) block in the depicted serving radio network controller (SRNC) and in the congestion determination and bitrate calculation of the Iub framing block of the radio base station NodeB. The goal of this FC is to efficiently use the TN in a fair manner.
Lack of a FC causes serious performance degradation when the TN is the bottleneck. In this case the TN buffer is typically full, causing high TN delay and loss ratio. This causes exhaustive Radio Link Control (RLC) retransmissions which results much lower throughput. In addition to this, RLC reset and a consequent Transmission Control Protocol (TCP) timeout can also occur.
The transport network bottleneck, i.e. between RNC and Radio Base Station (RBS) is handled by a TN flow control, which typically comprises:                Rate based flow-control with Additive Increased Multiplicative decrease (AIMD) operation.        Each flow has its own flow-control entity, e.g. separate independent congestion detection        Congestion is detected in the RBS based on the lost frames, i.e. gap in frame sequence numbers (FSN)        Congestion detection has a 100 ms aggregation        at least 1 lost frame is detected during the 100 ms interval by a flow then TN is considered congested during that period by that flow,        no frame loss during the 100 ms interval detected by a flow then TN is considered by that flow as non-congested.        Each flow has its own 100 ms tick timer (not synchronized). The 100 ms TN congestion status evaluation periods are not synchronized.        When a flow detects TN congestion, then the shaping rate in the RNC (maximal bitrate of the flow) is reduced to resolve congestion.        
Relative bitrate (RBR) feature is an extension to the flow-control. Basically this allows service differentiation into different flows with different performance. In one typical configuration the relative bitrate can be organized as: Gold, Silver, Bronze flows, where each of these flows is associated with different characteristics. Typically a set up can be as follows:                A Gold flow gets e.g. 2 times higher bandwidth share than a Silver flow        Additive Increase part of the flow control is modified to achieve the required bandwidth shares. Practically, a Gold flow has higher increase rate than a Silver flow and so on.        Weights are introduced for Gold, Silver and Bronze flows to describe a discrimination between the flows, e.g. 2, 1 and 0.5 for Gold, Silver and Bronze.        
In more detail the FC operates per-flow basis, where each HSDPA flow has its own (i) congestion detection, (ii) bitrate calculation and (iii) shaper part. The main tasks of these three parts are the following.
Congestion Detection Part in the Node B
Based on the arrived packets from the RNC, the congestion level of the TN is determined. If a TN congestion is determined this equals a congestion detection and the bitrate calculation part is informed accordingly.
Further a gap in sequence numbers of arriving packets is interpreted as “hard” congestion, because with a very high probability this event is due to packet loss in the TN caused by serious congestion. In addition to this, the variation of the one-way packet delay between RNC and Node B (a given fraction of packets have time-stamp) is measured. If this delay starts to increase, probably due to queue build up in the TN, this is interpreted it as “soft” congestion, but if this delay build up is getting too large (above a threshold e.g. larger than 60 ms) it can be interpreted as “hard” congestion too. The bitrate calculation part can be set to react on hard and soft congestions in differently.
Bitrate Calculation Part in the Node B
This part of the FC calculates the current maximum bitrate of the flow. This maximum bitrate is allowed by the TN for that flow. The applied algorithm conforms with the Additive Increase Multiplicative Decrease (AIMD) property that guarantees convergence to fairness; all flows converge to an equal share of resources in steady state, where no flows join or leave.
The FC maintains an internal variable for the maximum bitrate of the flow. This bitrate is increased linearly (or at least additively) if there is no TN congestion (no reported congestion from congestion detection part). If congestion is reported, the bitrate is reduced. The reduction can typically be 50% in case of hard congestion and 10% in case of soft congestion. When a new flow arrives, a new FC entity is created. A slow-start mechanism can be used to find out the proper starting bitrate of the new flow. After the first congestion the FC behaves according to the above described AIMD manner.
If the calculated bitrate of the flow changes (significantly), then the shaper will be informed about the new bitrate through a control frame called as Capacity Allocation (CA). To avoid too high processing load, this part of the FC is executed periodically with, e.g. a 100-ms period.
Flow Shaper in the RNC
The task of the shaper is to shape the flow according to the signaled maximum flow bitrate. This bitrate is coming from the latest received CA control frame.
The fairness of TN flow-control using the three parts as described above mainly depends on the fairness of TN congestion detection. If the congestion detection is unfair the bandwidth share of flows will be also unfair.                All flows have to detect the TN congestion. When only some flows detect congestion and are involved in resolving the congestion, the fairness will be poor. (Other flows do not detect congestion and in this way they do not decrease their bitrates.)        The number of lost frames (per flow) is approximately proportional with the bitrate of the flow. Flow with higher bitrate has higher amount of packets during a period and in this way has a higher chance for packet loss.        
There is a constant demand to provide radio system that is able to give a fair TN flow-control. Hence, there exist a need for a method and a system that is able to provide a flow control that is fair.